linux-next.git/include/linux/pinctrl, branch master

pinctrl: pinconf-generic: Add property 'input-debounce-ns'

2026-09-30T22:12:45+00:00

Add 'input-debounce-ns' to the generic parameters used for parsing DT files, along with the corresponding configuration parameter PIN_CONFIG_INPUT_DEBOUNCE_NS. This allows debounce time to be specified in nanoseconds as an alternative to the existing 'input-debounce' property which uses microseconds Signed-off-by: Changhuang Liang Signed-off-by: Linus Walleij

pinctrl: include linux/errno.h in consumer.h for ENOTSUPP

2026-09-24T11:09:00+00:00

The CONFIG_PINCTRL=n stubs of pinctrl_gpio_get_config() and pinctrl_gpio_set_config() return -ENOTSUPP, but the header only pulls in linux/err.h, which provides asm/errno.h and not the kernel-internal ENOTSUPP from linux/errno.h. A translation unit that includes pinctrl/consumer.h before anything else fails to build: include/linux/pinctrl/consumer.h:110:10: error: use of undeclared identifier 'ENOTSUPP' Include linux/errno.h explicitly. Fixes: b44aec87658e ("pinctrl: make the CONFIG_PINCTRL=n gpio config stubs return -ENOTSUPP") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202609240855.U59akHDO-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202609241240.61Hz5rix-lkp@intel.com/ Signed-off-by: Mehmet Fide Reviewed-by: Bartosz Golaszewski Signed-off-by: Linus Walleij

pinctrl: make the CONFIG_PINCTRL=n gpio config stubs return -ENOTSUPP

2026-09-20T22:13:34+00:00

With CONFIG_PINCTRL=n, pinctrl_gpio_get_config() and pinctrl_gpio_set_config() are stubs that return 0. The getter reports success without touching the config it was asked to fill, so a caller reads the packed parameter it passed in back as if it were the pin's state; the setter reports success for a configuration nobody applied. With CONFIG_PINCTRL=y the same callers already get -ENOTSUPP from gpiochip_generic_config() and gpiochip_generic_get_config() for a chip without pin ranges, and gpiolib treats that value as "the backend cannot do this" and carries on. Return it from the stubs too, so a kernel without pinctrl behaves like a chip without pin ranges instead of claiming success. Suggested-by: Haibo Chen Signed-off-by: Mehmet Fide Reviewed-by: Bartosz Golaszewski Signed-off-by: Linus Walleij

pinctrl: add optional .release_mux() callback

2026-05-05T12:48:12+00:00

Add an optional .release_mux() callback to struct pinmux_ops. Some drivers acquire additional resources in .set_mux(), such as software locks. These resources may need to be released when the mux function is no longer active. Introducing a dedicated .release_mux() callback allows drivers to clean up such resources. The callback is optional and does not affect existing drivers. Commit 2243a87d90b42 ("pinctrl: avoid duplicated calling enable_pinmux_setting for a pin") removed the .disable() callback to resolve two issues: 1. desc->mux_usecount increasing monotonically 2. Hardware glitches caused by repeated .disable()/.enable() calls Adding .release_mux() does not reintroduce those problems. The callback is intended only for releasing driver-side resources (e.g. locks) and must not modify hardware registers. Signed-off-by: Frank Li Signed-off-by: Linus Walleij

Merge branch 'ib-scmi-pinctrl-gpio' into devel

2026-03-24T12:50:44+00:00

pinctrl: introduce pinctrl_gpio_get_config()

2026-03-24T12:50:30+00:00

This is a counterpart of pinctrl_gpio_set_config(), which will be used to implement the ->get() interface in a GPIO driver for SCMI. This also requires that we create a stub so pin_config_get_for_pin() can build when CONFIG_PINCONF is disabled. Signed-off-by: AKASHI Takahiro Signed-off-by: Dan Carpenter Reviewed-by: Linus Walleij Reviewed-by: Andy Shevchenko Signed-off-by: Linus Walleij

pinctrl: pinconf-generic: Add properties 'input-threshold-voltage-microvolt'

2026-03-23T08:59:34+00:00

Add a new generic pin configuration parameter PIN_CONFIG_INPUT_VOLTAGE_UV. This parameter is used to specify the input voltage level of a pin in microvolts, which corresponds to the 'input-voltage-microvolt' property in Device Tree. Reviewed-by: Linus Walleij Signed-off-by: Tzuyi Chang Co-developed-by: Yu-Chun Lin Signed-off-by: Yu-Chun Lin Signed-off-by: Linus Walleij

pinctrl: pinconf-generic: fix an enum name description

2026-03-02T10:25:18+00:00

Correct an enum name in a kernel-doc comment to avoid kernel-doc warnings: Warning: include/linux/pinctrl/pinconf-generic.h:161 Enum value 'PIN_CONFIG_SKEW_DELAY_OUTPUT_PS' not described in enum 'pin_config_param' Warning: include/linux/pinctrl/pinconf-generic.h:161 Excess enum value '@PIN_CONFIG_SKEW_DELAY_OUPUT_PS' description in 'pin_config_param' Signed-off-by: Randy Dunlap Signed-off-by: Linus Walleij

pinctrl: generic: move function to amlogic-am4 driver

2026-02-06T11:07:14+00:00

pinconf_generic_dt_node_to_map_pinmux() is not actually a generic function, and really belongs in the amlogic-am4 driver. There are three reasons why. First, and least, of the reasons is that this function behaves differently to the other dt_node_to_map functions in a way that is not obvious from a first glance. This difference stems for the devicetree properties that the function is intended for use with, and how they are typically used. The other generic dt_node_to_map functions support platforms where the pins, groups and functions are described statically in the driver and require a function that will produce a mapping from dt nodes to these pre-established descriptions. No other code in the driver is require to be executed at runtime. pinconf_generic_dt_node_to_map_pinmux() on the other hand is intended for use with the pinmux property, where groups and functions are determined entirely from the devicetree. As a result, there are no statically defined groups and functions in the driver for this function to perform a mapping to. Other drivers that use the pinmux property (e.g. the k1) their dt_node_to_map function creates the groups and functions as the devicetree is parsed. Instead of that, pinconf_generic_dt_node_to_map_pinmux() requires that the devicetree is parsed twice, once by it and once at probe, so that the driver dynamically creates the groups and functions before the dt_node_to_map callback is executed. I don't believe this double parsing requirement is how developers would expect this to work and is not necessary given there are drivers that do not have this behaviour. Secondly and thirdly, the function bakes in some assumptions that only really match the amlogic platform about how the devicetree is constructed. These, to me, are problematic for something that claims to be generic. The other dt_node_to_map implementations accept a being called for either a node containing pin configuration properties or a node containing child nodes that each contain the configuration properties. IOW, they support the following two devicetree configurations: | cfg { | label: group { | pinmux = ; | config-item1; | }; | }; | label: cfg { | group1 { | pinmux = ; | config-item2; | }; | group2 { | pinmux = ; | config-item1; | }; | }; pinconf_generic_dt_node_to_map_pinmux() only supports the latter. The other assumption about devicetree configuration that the function makes is that the labeled node's parent is a "function node". The amlogic driver uses these "function nodes" to create the functions at probe time, and pinconf_generic_dt_node_to_map_pinmux() finds the parent of the node it is operating on's name as part of the mapping. IOW, it requires that the devicetree look like: | pinctrl@bla { | | func-foo { | label: group-default { | pinmuxes = ; | }; | }; | }; and couldn't be used if the nodes containing the pinmux and configuration properties are children of the pinctrl node itself: | pinctrl@bla { | | label: group-default { | pinmuxes = ; | }; | }; These final two reasons are mainly why I believe this is not suitable as a generic function, and should be moved into the driver that is the sole user and originator of the "generic" function. Signed-off-by: Conor Dooley Acked-by: Andy Shevchenko Signed-off-by: Linus Walleij

pinctrl: core: Remove unused devm_pinctrl_unregister()

2026-02-03T00:18:18+00:00

There are no users, drop it for good. Signed-off-by: Andy Shevchenko Reviewed-by: Bartosz Golaszewski Signed-off-by: Linus Walleij