linux-stable.git/drivers/pinctrl/mediatek, branch v6.18

pinctrl: mediatek: mt8189: align register base names to dt-bindings ones

2025-10-13T11:08:36+00:00

The mt8189-pinctrl driver requires to probe that a device tree uses
in the device node the same names than mt8189_pinctrl_register_base_names
array. But they are not matching the required ones in the
"mediatek,mt8189-pinctrl" dt-bindings, leading to possible dtbs check
issues. The mt8189_pinctrl_register_base_names entry order is also
different.
So, align all mt8189_pinctrl_register_base_names entry names and order
on dt-bindings.

Fixes: a3fe1324c3c5 ("pinctrl: mediatek: Add pinctrl driver for mt8189")
Signed-off-by: Louis-Alexis Eyraud 
Reviewed-by: AngeloGioacchino Del Regno 
Signed-off-by: Linus Walleij

pinctrl: mediatek: mt8196: align register base names to dt-bindings ones

2025-10-13T11:07:36+00:00

The mt8196-pinctrl driver requires to probe that a device tree uses
in the device node the same names than mt8196_pinctrl_register_base_names
array. But they are not matching the required ones in the
"mediatek,mt8196-pinctrl" dt-bindings, leading to possible dtbs check
issues.
So, align all mt8196_pinctrl_register_base_names entries on dt-bindings
ones.

Fixes: f7a29377c253 ("pinctrl: mediatek: Add pinctrl driver on mt8196")
Signed-off-by: Louis-Alexis Eyraud 
Reviewed-by: AngeloGioacchino Del Regno 
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: airoha: fix wrong MDIO function bitmaks

2025-09-08T21:01:19+00:00

With further testing with an attached Aeonsemi it was discovered that
the pinctrl MDIO function applied the wrong bitmask. The error was
probably caused by the confusing documentation related to these bits.

Inspecting what the bootloader actually configure, the SGMII_MDIO_MODE
is never actually set but instead it's set force enable to the 2 GPIO
(gpio 1-2) for MDC and MDIO pin.

The usage of GPIO might be confusing but this is just to instruct the
SoC to not mess with those 2 PIN and as Benjamin reported it's also an
Errata of 7581. The FORCE_GPIO_EN doesn't set them as GPIO function
(that is configured by a different register) but it's really to actually
""enable"" those lines.

Normally the SoC should autodetect this by HW but it seems AN7581 have
problem with this and require this workaround to force enable the 2 pin.

Applying this configuration permits correct functionality of any
externally attached PHY.

Cc: stable@vger.kernel.org
Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC")
Signed-off-by: Christian Marangi 
Acked-by: Benjamin Larsson 
Signed-off-by: Linus Walleij

pinctrl: airoha: fix wrong PHY LED mux value for LED1 GPIO46

2025-09-08T13:01:39+00:00

In all the MUX value for LED1 GPIO46 there is a Copy-Paste error where
the MUX value is set to LED0_MODE_MASK instead of LED1_MODE_MASK.

This wasn't notice as there were no board that made use of the
secondary PHY LED but looking at the internal Documentation the actual
value should be LED1_MODE_MASK similar to the other GPIO entry.

Fix the wrong value to apply the correct MUX configuration.

Cc: stable@vger.kernel.org
Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC")
Signed-off-by: Christian Marangi 
Acked-by: Lorenzo Bianconi 
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: make struct pinfunction a pointer in struct function_desc

2025-09-08T12:22:41+00:00

We currently duplicate the entire struct pinfunction object in
pinmux_generic_add_pinfunction(). While this is inevitable when the
arguments come in split through pinmux_generic_add_function(), users of
pinmux_generic_add_pinfunction() will typically pass addresses of
structures in .rodata, meaning we can try to avoid the duplication with
the help from kmemdup_const(). To that end: don't wrap the entire struct
pinfunction in struct function_desc but rather just store the address.

Tested-by: Neil Armstrong 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Linus Walleij

pinctrl: constify pinmux_generic_get_function()

2025-09-08T12:22:33+00:00

With all users of struct function_desc limited to only accessing it using
the dedicated function and never modifying it, we can now constify the
return value of pinmux_generic_get_function() treewide.

Reviewed-by: Andy Shevchenko 
Reviewed-by: Geert Uytterhoeven  # renesas
Acked-by: Geert Uytterhoeven  # renesas
Tested-by: Neil Armstrong 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Linus Walleij

pinctrl: mediatek: moore: replace struct function_desc with struct pinfunction

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

struct function_desc is a wrapper around struct pinfunction with an
additional void *data pointer. This driver doesn't use the data pointer.
We're also working towards reducing the usage of struct function_desc in
pinctrl drivers - they should only be created by pinmux core and
accessed by drivers using pinmux_generic_get_function(). Replace the
struct function_desc objects in this driver with smaller struct
pinfunction instances.

Reviewed-by: Chen-Yu Tsai 
Tested-by: Neil Armstrong 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Linus Walleij

pinctrl: mediatek: mt7988: use PINCTRL_PIN_FUNCTION()

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

We have a dedicated initializer macro for defining pin functions for
mediatek drivers so use it here.

Reviewed-by: Chen-Yu Tsai 
Reviewed-by: Andy Shevchenko 
Tested-by: Neil Armstrong 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Linus Walleij