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.
Michal Simek [Mon, 16 Jun 2025 07:43:18 +0000 (09:43 +0200)]
dt-bindings: gpio: gpio-xilinx: Mark clocks as required property
On Microblaze platforms there is no need to handle clocks because the
system is starting with clocks enabled (can be described via fixed clock
node or clock-frequency property or not described at all).
With using soft IPs with SOC platforms there is mandatory to handle clocks
as is explained in commit 60dbdc6e08d6 ("dt-bindings: net: emaclite: Add
clock support").
That's why make clock as required in dt binding because it is present in
both configurations and should be described even there is no way how to
handle it on Microblaze systems.
There is also need to describe missing axi gpio clock in fpga-region.yaml
not to introduce new error when make dt_binding_check runs.
gpio: sloppy-logic-analyzer: Fully open-code compatible for grepping
It is very useful to find driver implementing compatibles with `git grep
compatible`, so driver should not use defines for that string, even if
this means string will be effectively duplicated.
gpio: Use dev_fwnode() where applicable across drivers
irq_domain_create_simple() takes fwnode as the first argument. It can be
extracted from the struct device using dev_fwnode() helper instead of
using of_node with of_fwnode_handle().
gpio: TODO: add a task for removing MMIO-specific fields from gpio_chip
Currently for CONFIG_GPIO_GENERIC=y each struct gpio_chip object
contains the fields relevant only for gpio-mmio users. It's not an
insignificant number either as it's several pointers and integers.
It makes sense to remove these fields from struct gpio_chip into a
dedicated structure but this is not trivial due to how the bgpio_init()
function is implemented.
Frank Li [Mon, 2 Jun 2025 14:42:58 +0000 (10:42 -0400)]
dt-bindings: gpio: convert nxp,lpc1850-gpio.txt to yaml format
Convert nxp,lpc1850-gpio.txt to yaml format.
Additional changes:
- remove interrupt-controller and #interupt-cells from required list to
match existed dts files.
- remove gpio consumer in examples.
Andy Shevchenko [Sat, 31 May 2025 19:55:44 +0000 (22:55 +0300)]
gpiolib: Move GPIO_DYNAMIC_* constants to its only user
There is no need to export GPIO_DYNAMIC_* constants, especially via
legacy header which is subject to remove. Move the mentioned constants
to its only user, i.e. gpiolib.c.
projects / thirdparty / kernel / linux.git / log
