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.
Linus Torvalds [Sun, 8 Jun 2025 18:33:00 +0000 (11:33 -0700)]
Merge tag 'timers-cleanups-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer cleanup from Thomas Gleixner:
"The delayed from_timer() API cleanup:
The renaming to the timer_*() namespace was delayed due massive
conflicts against Linux-next. Now that everything is upstream finish
the conversion"
* tag 'timers-cleanups-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
treewide, timers: Rename from_timer() to timer_container_of()
Linus Torvalds [Sun, 8 Jun 2025 18:27:20 +0000 (11:27 -0700)]
Merge tag 'x86-urgent-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Thomas Gleixner:
"A small set of x86 fixes:
- Cure IO bitmap inconsistencies
A failed fork cleans up all resources of the newly created thread
via exit_thread(). exit_thread() invokes io_bitmap_exit() which
does the IO bitmap cleanups, which unfortunately assume that the
cleanup is related to the current task, which is obviously bogus.
Make it work correctly
- A lockdep fix in the resctrl code removed the clearing of the
command buffer in two places, which keeps stale error messages
around. Bring them back.
- Remove unused trace events"
* tag 'x86-urgent-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
fs/resctrl: Restore the rdt_last_cmd_clear() calls after acquiring rdtgroup_mutex
x86/iopl: Cure TIF_IO_BITMAP inconsistencies
x86/fpu: Remove unused trace events
projects / thirdparty / kernel / linux.git / log
