kernel/linux.git/drivers/pinctrl/meson, branch v6.19.11

pinctrl: meson: amlogic-a4: Fix device node reference leak in aml_dt_node_to_map_pinmux()

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

[ Upstream commit a2539b92e4b791c1ba482930b5e51b1591975461 ] The of_get_parent() function returns a device_node with an incremented reference count. Use the __free(device_node) cleanup attribute to ensure of_node_put() is automatically called when pnode goes out of scope, fixing a reference leak. Fixes: 6e9be3abb78c ("pinctrl: Add driver support for Amlogic SoCs") Signed-off-by: Felix Gu Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: generic: move function to amlogic-am4 driver

2026-03-12T11:09:42+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: meson: amlogic-a4: mark the GPIO controller as sleeping

2026-03-04T12:21:07+00:00

[ Upstream commit d6df4abe95a409e812c5d9af9657fe63ac299e3a ] The GPIO controller is configured as non-sleeping but it uses generic pinctrl helpers which use a mutex for synchronization. This will cause lockdep splats when used together with shared GPIOs going through the GPIO shared proxy driver. Fixes: 6e9be3abb78c ("pinctrl: Add driver support for Amlogic SoCs") Cc: stable@vger.kernel.org Reported-by: Martin Blumenstingl Closes: https://lore.kernel.org/all/CAFBinCAc7CO8gfNQakCu3LfkYXuyTd2iRpMRm8EKXSL0mwOnJw@mail.gmail.com/ Signed-off-by: Bartosz Golaszewski Reviewed-by: Martin Blumenstingl Reviewed-by: Neil Armstrong Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: meson: amlogic-a4: Fix device node reference leak in bank helpers

2026-02-26T23:01:27+00:00

[ Upstream commit e56aa18eba32fb68ac5e19e44670010095bb189c ] of_parse_phandle_with_fixed_args() increments the reference count of the returned device node, so it must be explicitly released using of_node_put() after use. Fix the reference leak in aml_bank_pins() and aml_bank_number() by adding the missing of_node_put() calls. Fixes: 6e9be3abb78c ("pinctrl: Add driver support for Amlogic SoCs") Signed-off-by: Felix Gu Reviewed-by: Xianwei Zhao Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: meson: mark the GPIO controller as sleeping

2026-01-19T00:13:22+00:00

The GPIO controller is configured as non-sleeping but it uses generic pinctrl helpers which use a mutex for synchronization. This can cause the following lockdep splat with shared GPIOs enabled on boards which have multiple devices using the same GPIO: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 142, name: kworker/u25:3 preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. irq event stamp: 46379 hardirqs last enabled at (46379): [] _raw_spin_unlock_irqrestore+0x74/0x78 hardirqs last disabled at (46378): [] _raw_spin_lock_irqsave+0x84/0x88 softirqs last enabled at (46330): [] handle_softirqs+0x4c4/0x4dc softirqs last disabled at (46295): [] __do_softirq+0x14/0x20 CPU: 1 UID: 0 PID: 142 Comm: kworker/u25:3 Tainted: G C 6.19.0-rc4-next-20260105+ #11963 PREEMPT Tainted: [C]=CRAP Hardware name: Khadas VIM3 (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x24 __might_resched+0x144/0x248 __might_sleep+0x48/0x98 __mutex_lock+0x5c/0x894 mutex_lock_nested+0x24/0x30 pinctrl_get_device_gpio_range+0x44/0x128 pinctrl_gpio_set_config+0x40/0xdc gpiochip_generic_config+0x28/0x3c gpio_do_set_config+0xa8/0x194 gpiod_set_config+0x34/0xfc gpio_shared_proxy_set_config+0x6c/0xfc [gpio_shared_proxy] gpio_do_set_config+0xa8/0x194 gpiod_set_transitory+0x4c/0xf0 gpiod_configure_flags+0xa4/0x480 gpiod_find_and_request+0x1a0/0x574 gpiod_get_index+0x58/0x84 devm_gpiod_get_index+0x20/0xb4 devm_gpiod_get+0x18/0x24 mmc_pwrseq_emmc_probe+0x40/0xb8 platform_probe+0x5c/0xac really_probe+0xbc/0x298 __driver_probe_device+0x78/0x12c driver_probe_device+0xdc/0x164 __device_attach_driver+0xb8/0x138 bus_for_each_drv+0x80/0xdc __device_attach+0xa8/0x1b0 Fixes: 6ac730951104 ("pinctrl: add driver for Amlogic Meson SoCs") Cc: stable@vger.kernel.org Reported-by: Marek Szyprowski Closes: https://lore.kernel.org/all/00107523-7737-4b92-a785-14ce4e93b8cb@samsung.com/ Signed-off-by: Bartosz Golaszewski Reviewed-by: Martin Blumenstingl Reviewed-by: Neil Armstrong Signed-off-by: Linus Walleij

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

2025-10-01T20:14:48+00:00

Pull pin control updates from Linus Walleij: "We have GPIO awareness in the pin control core and an interesting AAEON driver. Core changes: - Allow pins to be identified/marked as GPIO mode with a special callback. The pin controller core is now "aware" if a pin is in GPIO mode if the callback is implemented in the driver, and can thus be marked as "strict", i.e. disallowing simultaneous use of a line as GPIO and another function such as I2C. This is enabled in the Qualcomm TLMM driver and also implemeted from day 1 in the new Broadcom STB driver - Rename the pin config option PIN_CONFIG_OUTPUT to PIN_CONFIG_LEVEL to better describe what the config is doing, as well as making it more intuitive what shall be returned when reading this property New drivers: - Qualcomm SDM660 LPASS LPI TLMM pin controller subdriver - Qualcomm Glymur family pin controller driver - Broadcom STB family pin controller driver - Tegra186 pin controller driver - AAEON UP pin controller support. This is some special pin controller that works as an external advanced line MUX and amplifier for signals from an Intel SoC. A cooperative effort with the GPIO maintainer was needed to reach a solution where we reuse code from the GPIO aggregator/forwarder driver - Renesas RZ/T2H and RZ/N2H pin controller support - Axis ARTPEC-8 subdriver for the Samsung pin controller driver Improvements: - Output enable (OEN) support in the Renesas RZG2L driver - Properly support bias pull up/down in the pinctrl-single driver - Move over all GPIO portions using generic MMIO GPIO to the new generic GPIO chip management which has a nice and separate API - Proper DT bindings for some older Broadcom SoCs - External GPIO (EGPIO) support in the Qualcomm SM8250 Deleted code: - Dropped the now unused Samsung S3C24xx drivers" * tag 'pinctrl-v6.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (75 commits) pinctrl: use more common syntax for compound literals pinctrl: Simplify printks with pOF format pinctrl: qcom: Add SDM660 LPASS LPI TLMM dt-bindings: pinctrl: qcom: Add SDM660 LPI pinctrl pinctrl: qcom: lpass-lpi: Add ability to use custom pin offsets pinctrl: qcom: Add glymur pinctrl driver dt-bindings: pinctrl: qcom: Add Glymur pinctrl pinctrl: qcom: sm8250: Add egpio support pinctrl: generic: rename PIN_CONFIG_OUTPUT to LEVEL pinctrl: keembay: fix double free in keembay_build_functions() pinctrl: spacemit: fix typo in PRI_TDI pin name pinctrl: eswin: Fix regulator error check and Kconfig dependency pinctrl: bcm: Add STB family pin controller driver dt-bindings: pinctrl: Add support for Broadcom STB pin controller pinctrl: qcom: make the pinmuxing strict pinctrl: qcom: mark the `gpio` and `egpio` pins function as non-strict functions pinctrl: qcom: add infrastructure for marking pin functions as GPIOs pinctrl: allow to mark pin functions as requestable GPIOs pinctrl: qcom: use generic pin function helpers pinctrl: make struct pinfunction a pointer in struct function_desc ...

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: meson-gxl: add missing i2c_d pinmux

2025-08-28T21:06:03+00:00

Amlogic GXL has 4 I2C attached to gpio-periphs. I2C_D is on GPIOX_10/11. Add the relevant func 3 pinmux per the datasheet for S805X/S905X/S905D. Fixes: 0f15f500ff2c ("pinctrl: meson: Add GXL pinctrl definitions") Signed-off-by: Da Xue Link: https://lore.kernel.org/20250821233335.1707559-1-da@libre.computer Signed-off-by: Linus Walleij

pinctrl: meson-g12a: add GPIOC_7 pcie_clkreqn pinmux

2025-08-19T12:18:38+00:00

Amlogic G12 exposes PCIe clock request signal on GPIOC_7 pinmux func 1 Add the relevant pinmux and pin groups Signed-off-by: Da Xue Reviewed-by: Martin Blumenstingl Link: https://lore.kernel.org/20250814181236.1956731-1-da@libre.computer Signed-off-by: Linus Walleij

pinctrl: meson: Fix typo in device table macro

2025-08-18T09:10:47+00:00

The typo when using the MODULE_DEVICE_TABLE macro was not noticeable because the macro was defined only if the module was built as a separate module. Cc: Xianwei Zhao Cc: Linus Walleij Cc: Neil Armstrong Cc: Kevin Hilman Cc: linux-amlogic@lists.infradead.org Cc: linux-gpio@vger.kernel.org Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202507220009.8HKbNP16-lkp@intel.com/ Signed-off-by: Alexey Gladkov Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/e548b7761302defec15aa2098172eabb1ce1ad4a.1755170493.git.legion@kernel.org Signed-off-by: Linus Walleij