[PATCH v2] pinctrl: pinmux: Add missing .function_is_gpio kerneldoc

[PATCH v2] pinctrl: pinmux: Add missing .function_is_gpio kerneldoc

[Linus Walleij]

This callback was undocumented, add the docs.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Changes in v2:
- Think over how this function is actually used and make the docs
  more useful.
- Fix grammar and words.
- Link to v1: https://lore.kernel.org/r/20251014-function-is-gpio-kerneldoc-v1-1-4e6940a2b37f@linaro.org
---
 include/linux/pinctrl/pinmux.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/include/linux/pinctrl/pinmux.h b/include/linux/pinctrl/pinmux.h
index 6db6c3e1ccc2249d4b4204e6fc19bf7b4397cc81..468f38b7b7ed189cc0cae026e9715fc5f1683260 100644
--- a/include/linux/pinctrl/pinmux.h
+++ b/include/linux/pinctrl/pinmux.h
@@ -35,6 +35,16 @@ struct pinctrl_gpio_range;
  *	name can be used with the generic @pinctrl_ops to retrieve the
  *	actual pins affected. The applicable groups will be returned in
  *	@groups and the number of groups in @num_groups
+ * @function_is_gpio: determine if the indicated function selector passed
+ *	corresponds to the GPIO function which is used by the accelerared GPIO
+ *	functions @gpio_request_enable, @gpio_disable_free and
+ *	@gpio_set_direction. When the pin control core can properly determine
+ *	if a function is a GPIO function, it is easier to use the @strict mode
+ *	on the pin controller. Since a single function is passed, this is
+ *	only useful on pin controllers that use a specific function for GPIO,
+ *	and that usually presupposes that a one-group-per-pin approach is
+ *	used, so that a single function can be set on a single pin to turn
+ *	it to GPIO mode.
  * @set_mux: enable a certain muxing function with a certain pin group. The
  *	driver does not need to figure out whether enabling this function
  *	conflicts some other use of the pins in that group, such collisions

---
base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
change-id: 20251014-function-is-gpio-kerneldoc-29b9b9df9b2a

Best regards,
-- 
Linus Walleij <linus.walleij@linaro.org>