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.
gpio: mmio: get chip label and GPIO base from device properties
Ahead of removing struct bgpio_pdata support from the gpio-mmio generic
module, let's add support for getting the relevant values from generic
device properties. "label" is a semi-standardized property in some GPIO
drivers so let's go with it. There's no standard "base" property, so
let's use the name "gpio-mmio,base" to tie it to this driver
specifically. The number of GPIOs will be retrieved using
gpiochip_get_ngpios() so there's no need to look it up in the software
node.
gpio: reg: use new GPIO line value setter callbacks
struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. Convert the legacy generic
gpio-reg module to using them. We have to update the two legacy ARM
platforms that use it at the same time as they call the set_multiple()
callbacks directly (they shouldn't but it's old technical debt I
suppose).
GPIO core can handle output-only chips that don't implement the get()
and direction_input() callbacks. There's no need to provide dummy
implementations in the driver so drop them.
GPIO core can handle input-only chips that don't implement the
direction_output() callback at all. There's no need for the driver to
provide a dummy implementation so drop it.
Nuno Sá [Tue, 1 Jul 2025 14:32:12 +0000 (15:32 +0100)]
Input: adp5589: remove the driver
The adp5589 support is based on legacy platform data and there's no
upstream platform using this device.
Moreover, recently, with
commit 480a8ad683d7 ("mfd: adp5585: Add Analog Devices ADP5585 core support")
we overlapped support for the adp5585 device (gpiochip part of it) but
since it actually makes sense for the device to be supported under MFD, we
can complement it and add the keymap support for it (properly based on FW
properties). And that is what
commit 04840c5363a6 ("Input: adp5585: Add Analog Devices ADP5585/89 support")
Nuno Sá [Tue, 1 Jul 2025 14:32:11 +0000 (15:32 +0100)]
Input: adp5585: Add Analog Devices ADP5585/89 support
The ADP5585 is a 10/11 input/output port expander with a built in keypad
matrix decoder, programmable logic, reset generator, and PWM generator.
This driver supports the keyboard function using the platform device
registered by the core MFD driver.
The ADP5589 has 19 pins and also features an unlock function.
Nuno Sá [Tue, 1 Jul 2025 14:32:10 +0000 (15:32 +0100)]
gpio: adp5585: support gpi events
Add support for adding GPIs to the event FIFO. This is done by adding
irq_chip support. Like this, one can use the input gpio_keys driver as a
"frontend" device and input handler.
As part of this change, we now implement .request() and .free() as we can't
blindly consume all available pins as GPIOs (example: some pins can be
used for forming a keymap matrix).
Also note that the number of pins can now be obtained from the parent,
top level device. Hence the 'max_gpio' variable can be removed.
Nuno Sá [Tue, 1 Jul 2025 14:32:09 +0000 (15:32 +0100)]
mfd: adp5585: Add support for input devices
The ADP558x family supports a built in keypad matrix decoder which can
be added as an Input device. In order to both support the Input and the
GPIO device, we need to create a bitmap of the supported pins and track
their usage since they can either be used as GPIOs (GPIs) or as part of
the keymap.
We also need to mark special pins busy in case some features are being
used (ex: pwm or reset events).
Nuno Sá [Tue, 1 Jul 2025 14:32:08 +0000 (15:32 +0100)]
mfd: adp5585: Support reset and unlock events
The ADP558x family of devices can be programmed to respond to some
especial events, In case of the unlock events, one can lock the keypad
and use KEYS or GPIs events to unlock it. For the reset events, one can
again use a combinations of GPIs/KEYs in order to generate an event that
will trigger the device to generate an output reset pulse.
Nuno Sá [Tue, 1 Jul 2025 14:32:07 +0000 (15:32 +0100)]
mfd: adp5585: Add support for event handling
These devices are capable of generate FIFO based events based on KEY or
GPI presses. Add support for handling these events. This is in
preparation of adding full support for keymap and gpis based events.
Nuno Sá [Tue, 1 Jul 2025 14:32:06 +0000 (15:32 +0100)]
dt-bindings: mfd: adp5585: add properties for input events
Add properties related to input events. These devices can act as
keyboards and can support events either via a keymap Matrix or through
GPIs. Note that the device needs to be an interrupt controller for GPIs
based events.
We specifically need a property specifying the pins used by the keymap
matrix since these devices have no requirement for rows and columns to be
contiguous without holes which is enforced by the standard input
properties.
Nuno Sá [Tue, 1 Jul 2025 14:32:05 +0000 (15:32 +0100)]
pwm: adp5585: add support for adp5589
Add support for the adp5589 I/O expander. From a PWM point of view it is
pretty similar to adp5585. Main difference is the address
of registers meaningful for configuring the PWM.
Nuno Sá [Tue, 1 Jul 2025 14:32:04 +0000 (15:32 +0100)]
gpio: adp5585: add support for the adp5589 expander
Support the adp5589 I/O expander which supports up to 19 pins. We need
to add a chip_info based struct since accessing register "banks"
and "bits" differs between devices.
Also some register addresses are different.
While at it move ADP558X_GPIO_MAX defines to the main header file and
rename them. That information will be needed by the top level device in
a following change.
Nuno Sá [Tue, 1 Jul 2025 14:32:03 +0000 (15:32 +0100)]
mfd: adp5585: Add a per chip reg struture
There are some differences in the register map between the devices.
Hence, add a register structure per device. This will be needed in
following patches.
On top of that adp5585_fill_regmap_config() is renamed and reworked so
that the current struct adp5585_info act as template (they indeed
contain all the different data between variants) which can then be
complemented depending on the device (as identified by the id register).
This is done like this since a lot of the data is pretty much the same
between variants of the same device.
Nuno Sá [Tue, 1 Jul 2025 14:32:01 +0000 (15:32 +0100)]
mfd: adp5585: Refactor how regmap defaults are handled
The only thing changing between variants is the regmap default
registers. Hence, instead of having a regmap configuration for every
variant (duplicating lots of fields), add a chip info type of structure
with a regmap ID to identify which defaults to use and populate
regmap_config at runtime given a template plus the id. Also note that
between variants, the defaults can be the same which means the chip info
structure can be used in more than one compatible.
This will also make it simpler adding new chips with more variants.
Also note that the chip info structures are deliberately not const as
they will also contain lots of members that are the same between the
different devices variants and so we will fill those at runtime.
Nuno Sá [Tue, 1 Jul 2025 14:31:58 +0000 (15:31 +0100)]
mfd: adp5585: Enable oscillator during probe
Make sure to enable the oscillator in the top device. This will allow to
not control this in the child PWM device as that would not work with
future support for keyboard matrix where the oscillator needs to be
always enabled (and so cannot be disabled by disabling PWM).
Nuno Sá [Tue, 1 Jul 2025 14:31:57 +0000 (15:31 +0100)]
mfd: adp5585: Only add devices given in FW
Not all devices (features) of the adp5585 device are mandatory to be
used in all platforms. Hence, check what's given in FW and dynamically
create the mfd_cell array to be given to devm_mfd_add_devices().
Nuno Sá [Tue, 1 Jul 2025 14:31:56 +0000 (15:31 +0100)]
dt-bindings: mfd: adp5585: ease on the required properties
It is not mandatory to use all the capabilities of the device. One can
very well only use it as a gpio controller without the PWM support. This
will be even more evident when support for the matrix keymap is added.
Hence drop the requirements for PWM and GPIO.
It makes no sense for a GPIO descriptor comparator to return true when
the arguments passed to it are NULL or IS_ERR(). Let's validate both and
return false unless both are valid GPIO descriptors.
The GPIO core never passes empty bankmasks to the callbacks for handling
multiple signals at once. Remove the superfluous checks, and refactor
the code.
gpio: clps711x: drop unneeded platform_set_drvdata()
There's no corresponding platform_get_drvdata() used in this module or
the higher-level gpio-mmio. Let's remove the unneeded call to
platform_set_drvdata().
When invoking device_create_with_groups(), its return value is stored
in `data->cdev_base`. However, in case of faiure, `data` is first freed
and then derefernced in order to return `data->cdev_base`.
Fix the use-after-free by extracting the error code before free'ing
`data`.
gpio: sysfs: remove the mockdev pointer from struct gpio_device
The usage of the mockdev pointer in struct gpio_device is limited to the
GPIO sysfs code. There's no reason to keep it in this top-level
structure. Create a separate structure containing the reference to the
GPIO device and the dummy class device that will be passed to
device_create_with_groups(). The !gdev->mockdev checks can be removed as
long as we make sure that all operations on the GPIO class are protected
with the sysfs lock.
No symbols from the linux/idr.h or linux/spinlock.h headers are used in
this file so remove them. We also don't technically need linux/list.h
currently but one of the follow-up commits will start using it so let's
leave it.
Update the code to be more consistent with the rest of the codebase.
Mostly correctly align line-breaks, remove unneeded tabs, stray newlines
& spaces and tweak the comment style.
gpio: sysfs: call mutex_destroy() in gpiod_unexport()
While not critical, it's useful to have the corresponding call to
mutex_destroy() whenever we use mutex_init(). Add the call right before
kfreeing the GPIO data.
Since commit 700cdf7ed00f ("gpio: sysfs: make the sysfs export behavior
consistent"), named GPIO lines are no longer exported in sysfs as links
named after the them. Drop the misleading bit from the ABI docs.
We've converted this driver to using the new GPIO line value setters but
missed the instances where the legacy callback is accessed directly using
the function pointer. This will lead to a NULL-pointer dereference as
this pointer is no longer populated. The issue needs fixing locally as
well as in the already converted previously users of gpio-mmio.
Fixes: b908d35d0003 ("gpio: mmio: use new GPIO line value setter callbacks") Reported-by: Klara Modin <klarasmodin@gmail.com> Closes: https://lore.kernel.org/all/2rw2sncevdiyirpdovotztlg77apcq2btzytuv5jnm55aqhlne@swtts3hl53tw/ Tested-by: Klara Modin <klarasmodin@gmail.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250618-gpio-mmio-fix-setter-v1-2-2578ffb77019@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
gpio: npcm-sgpio: don't use legacy GPIO chip setters
We've converted this driver to using the new GPIO line value setters but
missed the instance where the legacy callback is accessed directly using
the function pointer. This will lead to a NULL-pointer dereference as
this pointer is no longer populated. Fix it.
gpio: mmio: add BGPIOF_NO_INPUT flag for GPO gpiochip
When using bgpio_init with a gpiochip acting as a GPO (output only), the
gpiochip ops `direction_input` was set to `bgpio_simple_dir_in` by
default but we have no input ability.
Adding this flag allows to set a valid ops for the `direction_output`
ops without setting a valid ops for `direction_input` by default.
projects / thirdparty / kernel / linux.git / log
