kernel/linux.git/drivers/pinctrl/nuvoton, branch v7.0.10

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

pinctrl: ma35: Convert to common field_{get,prep}() helpers

2025-11-24T19:15:47+00:00

Drop the driver-specific field_get() and field_prep() macros, in favor of the globally available variants from . Signed-off-by: Geert Uytterhoeven Reviewed-by: Linus Walleij Signed-off-by: Yury Norov (NVIDIA)

pinctrl: ma35: #undef field_{get,prep}() before local definition

2025-11-24T19:15:46+00:00

Prepare for the advent of globally available common field_get() and field_prep() macros by undefining the symbols before defining local variants. This prevents redefinition warnings from the C preprocessor when introducing the common macros later. Suggested-by: Yury Norov Signed-off-by: Geert Uytterhoeven Acked-by: Linus Walleij Signed-off-by: Yury Norov (NVIDIA)

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 ...

gpio: generic: rename BGPIOF_ flags to GPIO_GENERIC_

2025-09-24T11:52:35+00:00

Make the flags passed to gpio_generic_chip_init() use the same prefix as the rest of the modernized generic GPIO chip API. Link: https://lore.kernel.org/r/20250917-gpio-generic-flags-v1-1-69f51fee8c89@linaro.org Signed-off-by: Bartosz Golaszewski

pinctrl: use more common syntax for compound literals

2025-09-23T22:41:08+00:00

The (typeof(foo)) construct is unusual in the kernel, use a more typical syntax by explicitly spelling out the type. Link: https://lore.kernel.org/all/20250909-gpio-mmio-gpio-conv-part4-v1-13-9f723dc3524a@linaro.org/ Suggested-by: Andy Shevchenko Signed-off-by: Bartosz Golaszewski Reviewed-by: Andy Shevchenko 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

pinctrl: ma35: Use int type to store negative error codes

2025-09-08T12:21:06+00:00

Change the 'ret' variable in ma35_pinctrl_parse_functions() from u32 to int, as it needs to store either negative error codes or zero returned by ma35_pinctrl_parse_groups(). No effect on runtime. Signed-off-by: Qianfeng Rong Signed-off-by: Linus Walleij

pinctrl: wpcm450: use new generic GPIO chip API

2025-08-19T09:41:38+00:00

Convert the driver to using the new generic GPIO chip interfaces from linux/gpio/generic.h. Signed-off-by: Bartosz Golaszewski Link: https://lore.kernel.org/20250811-gpio-mmio-pinctrl-conv-v1-5-a84c5da2be20@linaro.org Signed-off-by: Linus Walleij