kernel/linux.git/include/linux/pinctrl/pinconf-generic.h, branch v6.18.22

pinctrl: generic: move function to amlogic-am4 driver

2026-03-12T11:09:47+00:00

[ Upstream commit 9c5a40f2922a5a6d6b42e7b3d4c8e253918c07a1 ] 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 Stable-dep-of: a2539b92e4b7 ("pinctrl: meson: amlogic-a4: Fix device node reference leak in aml_dt_node_to_map_pinmux()") Signed-off-by: Sasha Levin

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

pinctrl: pinconf-generic: Add API for pinmux propertity in DTS file

2025-02-27T23:03:17+00:00

When describing pin mux func through pinmux propertity, a standard API is added for support. The pinmux contains pin identification and mux values, which can include multiple pins. And groups configuration use other word. DTS such as: func-name { group_alias: group-name{ pinmux= , ; bias-pull-up; drive-strength-microamp = <4000>; }; }; Signed-off-by: Xianwei Zhao Link: https://lore.kernel.org/20250212-amlogic-pinctrl-v5-2-282bc2516804@amlogic.com Signed-off-by: Linus Walleij

pinctrl: pinconf-generic: Add support for "input-schmitt-microvolt" property

2024-08-03T22:54:49+00:00

Add "input-schmitt-microvolt" property to generic options used for DT parsing files. This enables drivers, which use generic pin configurations, to get the value passed to this property. Signed-off-by: Inochi Amaoto Link: https://lore.kernel.org/IA1PR20MB4953806785BA04E075DC4F03BBAC2@IA1PR20MB4953.namprd20.prod.outlook.com Signed-off-by: Linus Walleij

pinctrl: Convert unsigned to unsigned int

2023-12-04T14:32:42+00:00

Simple type conversion with no functional change implied. While at it, adjust indentation where it makes sense. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20231129161459.1002323-24-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij

pinconf-generic: fix style issues in pin_config_param doc

2022-11-21T13:38:28+00:00

Fixes following issues introduced in a previous commit to clarify values for pin config pull up and down types. - replace spaces with tabs to be consistent with rest of the doc - use capitalization for unit (ohms -> Ohms) Signed-off-by: Niyas Sait Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20221117123542.1154252-1-niyas.sait@linaro.org Signed-off-by: Linus Walleij

pinconf-generic: clarify pull up and pull down config values

2022-11-17T09:29:54+00:00

PIN_CONFIG_BIAS_PULL_DOWN and PIN_CONFIG_BIAS_PULL_UP values can be custom or an SI unit such as ohms Signed-off-by: Niyas Sait Link: https://lore.kernel.org/r/20221115175415.650690-3-niyas.sait@linaro.org Signed-off-by: Linus Walleij

pinctrl: Clean up headers

2022-10-24T14:06:48+00:00

There is a few things done: - include only the headers we are direct user of - when pointer is in use, provide a forward declaration - add missing headers - group generic headers and subsystem headers - sort each group alphabetically While at it, fix some awkward indentations. Signed-off-by: Andy Shevchenko

pinctrl: pinconf-generic: Add support for "output-impedance-ohms" to be extracted from DT files

2021-11-15T09:13:36+00:00

Add "output-impedance-ohms" property to generic options used for DT parsing files. This enables drivers, which use generic pin configurations, to get the value passed to this property. Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20211027134509.5036-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven

Merge tag 'pinctrl-v5.14-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl

2021-07-01T23:57:14+00:00

Pull pin control updates from Linus Walleij: "This is the bulk of pin control changes for the v5.14 kernel. Not so much going on. No core changes, just drivers. The most interesting would be that MIPS Ralink is migrating to pin control and we have some bindings but not yet code for the Apple M1 pin controller. New drivers: - Last merge window we created a driver for the Ralink RT2880. We are now moving the Ralink SoC pin control drivers out of the MIPS architecture code and into the pin control subsystem. This concerns RT288X, MT7620, RT305X, RT3883 and MT7621. - Qualcomm SM6125 SoC pin control driver. - Qualcomm spmi-gpio support for PM7325. - Qualcomm spmi-mpp also handles PMI8994 (just a compatible string) - Mediatek MT8365 SoC pin controller. - New device HID for the AMD GPIO controller. Improvements: - Pin bias config support for a slew of Renesas pin controllers. - Incremental improvements and non-urgent bug fixes to the Renesas SoC drivers. - Implement irq_set_wake on the AMD pin controller so we can wake up from external pin events. Misc: - Devicetree bindings for the Apple M1 pin controller, we will probably see a proper driver for this soon as well" * tag 'pinctrl-v5.14-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (54 commits) pinctrl: ralink: rt305x: add missing include pinctrl: stm32: check for IRQ MUX validity during alloc() pinctrl: zynqmp: some code cleanups drivers: qcom: pinctrl: Add pinctrl driver for sm6125 dt-bindings: pinctrl: qcom: sm6125: Document SM6125 pinctrl driver dt-bindings: pinctrl: mcp23s08: add documentation for reset-gpios pinctrl: mcp23s08: Add optional reset GPIO pinctrl: mediatek: fix mode encoding pinctrl: mcp23s08: Fix missing unlock on error in mcp23s08_irq() pinctrl: bcm: Constify static pinmux_ops pinctrl: bcm: Constify static pinctrl_ops pinctrl: ralink: move RT288X SoC pinmux config into a new 'pinctrl-rt288x.c' file pinctrl: ralink: move MT7620 SoC pinmux config into a new 'pinctrl-mt7620.c' file pinctrl: ralink: move RT305X SoC pinmux config into a new 'pinctrl-rt305x.c' file pinctrl: ralink: move RT3883 SoC pinmux config into a new 'pinctrl-rt3883.c' file pinctrl: ralink: move MT7621 SoC pinmux config into a new 'pinctrl-mt7621.c' file pinctrl: ralink: move ralink architecture pinmux header into the driver pinctrl: single: config: enable the pin's input pinctrl: mtk: Fix mt8365 Kconfig dependency pinctrl: mcp23s08: fix race condition in irq handler ...