lwn.git/drivers/pinctrl/stm32/pinctrl-stm32.c, branch docs-fixes

pinctrl: stm32: handle semaphore acquisition when handling pinctrl/pinmux

2025-11-10T22:59:00+00:00

When a GPIO RIF configuration is in semaphore mode, and the semaphore hasn't been taken before configuring the GPIO, the write operations silently fail. To avoid a silent fail when applying a pinctrl, if the pins that are being configured are in semaphore mode, take the semaphore. Note that there is no proper release of the RIF semaphore yet for pinctrl. Signed-off-by: Gatien Chevallier Signed-off-by: Linus Walleij

pinctrl: stm32: fix hwspinlock resource leak in probe function

2025-10-29T22:37:17+00:00

In stm32_pctl_probe(), hwspin_lock_request_specific() is called to request a hwspinlock, but the acquired lock is not freed on multiple error paths after this call. This causes resource leakage when the function fails to initialize properly. Use devm_hwspin_lock_request_specific() instead of hwspin_lock_request_specific() to automatically manage the hwspinlock resource lifecycle. Fixes: 97cfb6cd34f2 ("pinctrl: stm32: protect configuration registers with a hwspinlock") Signed-off-by: Haotian Zhang Reviewed-by: Antonio Borneo Signed-off-by: Linus Walleij

pinctrl: stm32: Support I/O synchronization parameters

2025-10-28T09:43:01+00:00

Devices in the stm32mp2xx family include an I/O synchronization block on each pin that is used to fine tune and improve the I/O timing margins of high speed synchronous interfaces. It can be configured to provide independently for each pin: - skew rate on input direction or latch delay on output direction; - inversion of clock signals or re-sampling of data signals. Add support for the generic properties: - skew-delay-input-ps; - skew-delay-output-ps. Add support for the property 'st,io-sync' to configure clock inversion or data re-sampling mode. Show the new parameters on debugfs pinconf-pins. Enable it for the stm32mp257 pinctrl driver. Co-developed-by: Valentin Caron Signed-off-by: Valentin Caron Co-developed-by: Fabien Dessenne Signed-off-by: Fabien Dessenne Signed-off-by: Antonio Borneo Signed-off-by: Linus Walleij

pinctrl: stm32: Avoid keeping a bool value in a u32 variable

2025-10-28T09:43:01+00:00

Change type of variable to avoid keeping the bool return value in a variable of u32 type. Signed-off-by: Antonio Borneo Signed-off-by: Linus Walleij

pinctrl: stm32: Drop useless spinlock save and restore

2025-10-28T09:43:01+00:00

There is no need to acquire a spinlock to only read a register for debugfs reporting. Drop such useless spinlock save and restore. Signed-off-by: Antonio Borneo Signed-off-by: Linus Walleij

pinctrl: stm32: Simplify handling of backup pin status

2025-10-28T09:43:01+00:00

Use C bit-field to keep the backup of the pin status, instead of explicitly handling the bit-field through shift and mask of a u32 container. Signed-off-by: Antonio Borneo Signed-off-by: Linus Walleij

pinctrl: stm32: Rework stm32_pconf_parse_conf()

2025-10-28T09:43:01+00:00

Reduce the number of parameters of the function by moving inside the function the decoding of the field 'config'. While there: - change the type of 'param' to 'unsigned int' to handle the extra values not in 'enum pin_config_param'; - change the type of 'arg' to 'u32' to avoid additional conversions and align to 'u32' the corresponding param of __stm32_gpio_set(). Signed-off-by: Antonio Borneo Signed-off-by: Linus Walleij

pinctrl: generic: rename PIN_CONFIG_OUTPUT to LEVEL

2025-09-08T12:24:20+00:00

This generic pin config property is confusingly named so let's rename it to make things clearer. There are already drivers in the tree that use PIN_CONFIG_OUTPUT to *read* the value of an output driven pin, which is a big semantic confusion for the head: are we then reading the setting of the output or the actual value/level that is put out on the pin? We already have PIN_CONFIG_OUTPUT_ENABLE that turns on driver buffers for output, so this can by logical conclusion only drive the voltage level if it should be any different. But if we read the pin, are we then reading the *setting* of the output value or the *actual* value we can see on the line? If the pin has not first been set into output mode with PIN_CONFIG_OUTPUT_ENABLE, but is instead in some input mode or tristate, what will reading this property actually return? Reading the current users reading this property it is clear that what we read is the logical level of the pin as 0 or 1 depending on if it is low or high. Rename it to PIN_CONFIG_LEVEL so it is crystal clear that we set or read the voltage level of the pin and nothing else. Acked-by: Sudeep Holla Signed-off-by: Linus Walleij

treewide: rename GPIO set callbacks back to their original names

2025-08-07T08:07:06+00:00

The conversion of all GPIO drivers to using the .set_rv() and .set_multiple_rv() callbacks from struct gpio_chip (which - unlike their predecessors - return an integer and allow the controller drivers to indicate failures to users) is now complete and the legacy ones have been removed. Rename the new callbacks back to their original names in one sweeping change. Signed-off-by: Bartosz Golaszewski

pinctrl: stm32: Handle RSVD pin configuration

2025-06-18T09:23:57+00:00

When a pin is assigned to a coprocessor not running Linux, the pin should be flagged in the DT as reserved and not usable by Linux. Add pin configuration RSVD (Reserved) and instrument the driver to not update the mux setting. Signed-off-by: Fabien Dessenne Signed-off-by: Antonio Borneo Link: https://lore.kernel.org/20250610152309.299438-2-antonio.borneo@foss.st.com Signed-off-by: Linus Walleij