kernel/linux.git/drivers/pinctrl/cirrus, branch v6.18.22

pinctrl: cirrus: cs42l43: Fix double-put in cs42l43_pin_probe()

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

[ Upstream commit fd5bed798f45eb3a178ad527b43ab92705faaf8a ] devm_add_action_or_reset() already invokes the action on failure, so the explicit put causes a double-put. Fixes: 9b07cdf86a0b ("pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()") Signed-off-by: Felix Gu Reviewed-by: Charles Keepax Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()

2025-11-09T23:01:22+00:00

The driver calls fwnode_get_named_child_node() which takes a reference on the child node, but never releases it, which causes a reference leak. Fix by using devm_add_action_or_reset() to automatically release the reference when the device is removed. Fixes: d5282a539297 ("pinctrl: cs42l43: Add support for the cs42l43") Suggested-by: Charles Keepax Signed-off-by: Haotian Zhang 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: cirrus: cs42l43: use new GPIO line value setter callbacks

2025-06-18T12:05:29+00:00

struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Signed-off-by: Bartosz Golaszewski Reviewed-by: Charles Keepax Link: https://lore.kernel.org/20250612-gpiochip-set-rv-pinctrl-cirrus-v1-2-2d45c1f92557@linaro.org Signed-off-by: Linus Walleij

pinctrl: cirrus: lochnagar: use new GPIO line value setter callbacks

2025-06-18T12:05:29+00:00

struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Signed-off-by: Bartosz Golaszewski Reviewed-by: Charles Keepax Link: https://lore.kernel.org/20250612-gpiochip-set-rv-pinctrl-cirrus-v1-1-2d45c1f92557@linaro.org Signed-off-by: Linus Walleij

pinctrl: Constify static 'pinctrl_desc'

2025-06-18T11:26:37+00:00

The local static 'struct pinctrl_desc' is not modified, so can be made const for code safety. Acked-by: Lorenzo Bianconi Acked-by: Jesper Nilsson Reviewed-by: Charles Keepax Signed-off-by: Krzysztof Kozlowski Reviewed-by: Hal Feng Acked-by: Emil Renner Berthing Acked-by: Vladimir Zapolskiy Link: https://lore.kernel.org/20250611-pinctrl-const-desc-v2-16-b11c1d650384@linaro.org Signed-off-by: Linus Walleij

pinctrl: cirrus: madera-core: Use devm_pinctrl_register_mappings()

2025-06-10T12:44:42+00:00

Use devm_pinctrl_register_mappings(), so the mappings are automatically unregistered by the core. If pinctrl_enable() failed during the probe, pinctrl_mappings were not freed. Now it is done by the core. Fixes: 218d72a77b0b ("pinctrl: madera: Add driver for Cirrus Logic Madera codecs") Signed-off-by: Thomas Richard Reviewed-by: Richard Fitzgerald Link: https://lore.kernel.org/20250609-pinctrl-madera-devm-pinctrl-register-mappings-v1-1-ba2c2822cf6c@bootlin.com Signed-off-by: Linus Walleij

pinctrl: Use str_enable_disable-like helpers

2025-01-15T11:52:26+00:00

Replace ternary (condition ? "enable" : "disable") syntax with helpers from string_choices.h because: 1. Simple function call with one argument is easier to read. Ternary operator has three arguments and with wrapping might lead to quite long code. 2. Is slightly shorter thus also easier to read. 3. It brings uniformity in the text - same string. 4. Allows deduping by the linker, which results in a smaller binary file. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Florian Fainelli Reviewed-by: Antonio Borneo Reviewed-by: Charles Keepax Link: https://lore.kernel.org/20250114203602.1013275-1-krzysztof.kozlowski@linaro.org Signed-off-by: Linus Walleij

pinctrl: Switch back to struct platform_driver::remove()

2024-10-11T19:45:47+00:00

After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/pinctrl to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/20241007205803.444994-8-u.kleine-koenig@baylibre.com Signed-off-by: Linus Walleij