Add support for the TI TPS65214 PMIC with the addition of an id_table,
separate TPS65214 template_chip, and device-specific _change_direction
functions.
- Use platform_get_device_id() to assign dev-specific information.
- Use different change_direction() functions since TPS65214's GPIO
configuration bits are changeable during device operation through bit
GPIO_CONFIG in GENERAL_CONFIG register.
- Remove MODULE_ALIAS since it is now generated by MODULE_DEVICE_TABLE.
Reviewed-by: Jonathan Cormier <jcormier@criticallink.com> Tested-by: Jonathan Cormier <jcormier@criticallink.com> Signed-off-by: Shree Ramamoorthy <s-ramamoorthy@ti.com> Link: https://lore.kernel.org/r/20250722181609.1541739-3-s-ramamoorthy@ti.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
TPS65215 and TPS65219 are overlapping PMIC devices. While their regulator
features differe, the GPIO features are the same. In the TPS65219 MFD
driver, the 2 PMICs share the same "tps65219-gpio" compatible string to
limit support for TPS65215 in this GPIO driver to comments.
The TPS6521X_GPIO0_IDX and TPS6521X_GPIO0_OFFSET macro name prefixes are
updated to indicate these macros apply to both PMICs.
Dan Carpenter [Fri, 18 Jul 2025 21:22:15 +0000 (16:22 -0500)]
gpio: sysfs: Fix an end of loop test in gpiod_unexport()
The test for "if (!desc_data)" does not work correctly because the list
iterator in a list_for_each_entry() loop is always non-NULL. If we don't
exit via a break, then it points to invalid memory. Instead, use a tmp
variable for the list iterator and only set the "desc_data" when we have
found a match.
The fsl,mpc8349-gpio, fsl,mpc8572-gpio, and fsl,mpc8610-gpio compatibles
are already documented in fsl,qoriq-gpio.yaml. Add the additional
compatibles that use fsl,mpc8349-gpio as a fallback. With that,
the 8xxx_gpio.txt binding document is redundant and can be removed.
Many simple GPIO controllers without interrupt capability have the same
schema other than their compatible value. Combine all these bindings
into a single schema. The criteria to be included here is must use 2
cells, have no interrupt capability, have 0 or 1 "reg" entries, and
have no other resources (like clocks).
Note that "ngpios" is now allowed in some cases it wasn't before and
constraints on it have been dropped.
gpio: xilinx: convert set_multiple() to the new API as well
The patch converting the driver to using new GPIO line value setters
only converted the set() callback and missed set_multiple(). Fix it now.
Fixes: 1919ea19a4ff ("gpio: xilinx: use new GPIO line value setter callbacks") Acked-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/20250717131116.53878-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
As of commit 92ac7de3175e3 ("gpiolib: don't allow setting values on input
lines"), the GPIO core makes sure values cannot be set on input lines.
Remove the unnecessary check.
Add the interrupt enable register offset (inten_offset) so that GPIO
interrupts can be enabled normally on more models.
According to the latest interface specifications, the definition of GPIO
interrupts in ACPI is similar to that in FDT. The GPIO interrupts are
listed one by one according to the GPIO number, and the corresponding
interrupt number can be obtained directly through the GPIO number
specified by the consumer.
gpio: sysfs: allow disabling the legacy parts of the GPIO sysfs interface
Add a Kconfig switch allowing to disable the legacy parts of the GPIO
sysfs interface. This means that even though we keep the
/sys/class/gpio/ directory, it no longer contains the global
export/unexport attribute pair (instead, the user should use the
per-chip export/unpexport) nor the gpiochip$BASE entries. This option
default to y if GPIO sysfs is enabled but we'll default it to n at some
point in the future.
gpio: sysfs: export the GPIO directory locally in the gpiochip<id> directory
As a way to allow the user-space to stop referring to GPIOs by their
global numbers, introduce a parallel group of line attributes for
exported GPIO that live inside the GPIO chip class device and are
referred to by their HW offset within their parent chip.
gpio: sysfs: don't look up exported lines as class devices
In preparation for adding a parallel, per-chip attribute group for
exported GPIO lines, stop using class device APIs to refer to it in the
code. When unregistering the chip, don't call class_find_device() but
instead store exported lines in a linked list inside the GPIO chip data
object and look it up there.
gpio: sysfs: don't use driver data in sysfs callbacks for line attributes
Currently each exported GPIO is represented in sysfs as a separate class
device. This allows us to simply use dev_get_drvdata() to retrieve the
pointer passed to device_create_with_groups() from sysfs ops callbacks.
However, we're preparing to add a parallel set of per-line sysfs
attributes that will live inside the associated gpiochip group. They are
not registered as class devices and so have the parent device passed as
argument to their callbacks (the GPIO chip class device).
Put the attribute structs inside the GPIO descriptor data and
dereference the relevant ones using container_of() in the callbacks.
This way, we'll be able to reuse the same code for both the legacy and
new GPIO attributes.
gpio: sysfs: rename the data variable in gpiod_(un)export()
In preparation for future commits which will make use of descriptor AND
GPIO-device data in the same functions rename the former from data to
desc_data separately which will make future changes smaller and easier
to read.
gpio: sysfs: pass gpiod_data directly to internal GPIO sysfs functions
We don't use any fields from struct device in gpio_sysfs_request_irq(),
gpio_sysfs_free_irq() and gpio_sysfs_set_active_low(). We only use the
dev argument to get the associated struct gpiod_data pointer with
dev_get_drvdata().
To make the transition to not using dev_get_drvdata() across line
callbacks for sysfs attributes easier, pass gpiod_data directly to
these functions instead of having it wrapped in struct device.
gpio: sysfs: only get the dirent reference for the value attr once
There's no reason to retrieve the reference to the sysfs dirent every
time we request an interrupt, we can as well only do it once when
exporting the GPIO.
gpio: sysfs: add a parallel class device for each GPIO chip using device IDs
In order to enable moving away from the global GPIO numberspace-based
exporting of lines over sysfs: add a parallel, per-chip entry under
/sys/class/gpio/ for every registered GPIO chip, denoted by device ID
in the file name and not its base GPIO number.
Compared to the existing chip group: it does not contain the "base"
attribute as the goal of this change is to not refer to GPIOs by their
global number from user-space anymore. It also contains its own,
per-chip export/unexport attribute pair which allow to export lines by
their hardware offset within the chip.
Caveat #1: the new device cannot be a link to (or be linked to by) the
existing "gpiochip<BASE>" entry as we cannot create links in
/sys/class/xyz/.
Caveat #2: the new entry cannot be named "gpiochipX" as it could
conflict with devices whose base is statically defined to a low number.
Let's go with "chipX" instead.
While at it: the chip label is unique so update the untrue statement
when extending the docs.
gpio: sysfs: use gpiod_is_equal() to compare GPIO descriptors
We have a dedicated comparator for GPIO descriptors that performs
additional checks and hides the implementation detail of whether the
same GPIO can be associated with two separate struct gpio_desc objects.
Use it in sysfs code
Hugo Villeneuve [Mon, 14 Jul 2025 13:37:30 +0000 (09:37 -0400)]
gpio: pca953x: use regmap_update_bits() to improve performance
Using regmap_update_bits() allows to reduce the number of I2C transfers
when updating bits that haven't changed on non-volatile registers.
For example on a PCAL6416, when changing a GPIO direction from input to
output, the number of I2C transfers can be reduced from 4 to just 1 if
the pull resistors configuration hasn't changed and the output value
is the same as before.
GPIO core already makes sure that offsets higher than the number of GPIOs
are never passed to controller callbacks. We can remove the unnecessary
check.
gpio: wcd934x: check the return value of regmap_update_bits()
regmap_update_bits() can fail so check its return value in
wcd_gpio_direction_output() for consistency with the rest of the code
and propagate any errors.
gpiolib: don't use GPIO global numbers in debugfs output
One of the users of global GPIO numbers in the kernel are the debugfs
callbacks in GPIO drivers. Before converting any custom .dbg_show()
callbacks in individual modules, let's first make GPIO core stop using
GPIO base in debugfs output. Use hardware offsets instead.
Convert the Renesas R-Car GPIO driver from SIMPLE_DEV_PM_OPS() to
DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr(). This lets us drop the
check for CONFIG_PM_SLEEP, and reduces kernel size in case CONFIG_PM or
CONFIG_PM_SLEEP is disabled, while increasing build coverage.
gpio: sim: allow to mark simulated lines as invalid
Add a new line-level, boolean property to the gpio-sim configfs
interface called 'valid'. It's set by default and the user can unset it
to make the line be included in the standard `gpio-reserved-ranges`
property when the chip is registered with GPIO core. This allows users
to specify which lines should not be available for requesting as GPIOs.
Maria Garcia [Thu, 3 Jul 2025 20:57:40 +0000 (22:57 +0200)]
gpio: pca953x: Add support for TI TCA6418
The TI TCA6418 is a 18-channel I2C I/O expander. It is slightly
different to other models from the same family, such as TCA6416,
but has enough in common with them to make it work with just a
few tweaks, which are explained in the code's documentation.
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to
pm_runtime_mark_last_busy().
GPIO core can handle output-only chips that don't implement the get()
and direction_input() callbacks. There's no need to provide dummy
implementation of the latter in the driver so drop it.
GPIO core can handle output-only chips that don't implement the get()
and direction_input() callbacks. There's no need to provide dummy
implementation of the latter in the driver so drop it.
gpio: tegra186: don't call the set() callback directly
Drivers should not dereference GPIO chip callbacks directly. Move the
module's set() function higher to make it available to the
direction_output() callback and call it instead.
As the first step in removing the fields specific to the gpio-mmio
module from struct gpio_chip, we introduce a new set of generic GPIO
chip interfaces that are meant to replace the existing bgpio_ ones.
The new initialization function - gpio_generic_chip_init() - takes a
configuration structure as argument instead of 9 separate parameters.
This will allow easy extension if needed in the future. We hide the
locking details behind a set of helpers in order to be able to move the
raw spinlock out of struct gpio_chip without the users noticing.
For now, the new APIs just wrap the existing ones. Once all users have
been converted to the new interfaces, we'll pull them into gpio-mmio and
implement them in a backward-compatible way while also moving all fields
specific to the generic GPIO chip into struct gpio_generic_chip.
With no more users, we can now remove struct bgpio_pdata. Move the
relevant bits from bgpio_parse_fw() into bgpio_pdev_probe() while
maintaining the logical ordering (get flags before calling
bgpio_init()).
ARM: s3c: crag6410: use generic device properties for gpio-mmio
The GPIO device in crag6410 is registered with struct bgpio_pdata passed
as platform_data to the gpio-mmio driver. We want to remove the
bgpio_pdata from the kernel and the gpio-mmio driver is now also able to
get the relevant values from the software node. Set up device properties
and switch to using platform_device_info to register the device as
platform_add_devices() doesn't allow us to pass device properties to the
driver model.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20250701-gpio-mmio-pdata-v2-5-ebf34d273497@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
ARM: omap1: ams-delta: use generic device properties for gpio-mmio
The two latch GPIO devices in ams-delta are registered with struct
bgpio_pdata passed as platform_data to the gpio-mmio driver. We want to
remove the bgpio_pdata from the kernel and the gpio-mmio driver is now
also able to get the relevant values from the software node. Set up
device properties and switch to using platform_device_info to register
the devices as platform_add_devices() doesn't allow us to pass device
properties to the driver model.
mfd: vexpress-sysreg: set-up software nodes for gpio-mmio
Replace struct bgpio_pdata - that we plan to remove - with software
nodes containing properties encoding the same values thatr can now be
parsed by gpio-mmio.
projects / thirdparty / kernel / linux.git / log
