Pull pin control updates from Linus Walleij:
 "Core changes:

   - Add new generic callbacks to populate per-pin pin controllers
     creating groups and functions from the device tree building out
     pinctrl_generic_to_map() and move the Spacemit driver over to use
     this

   - Generic board-level pin control driver using the mux framework

  New pin controller drivers:

   - Amlogic (meson) A9 SoC

   - Aspeed AST2700 SoC0 and SoC1

   - nVidia Tegra264 and Tegra238

   - Qualcomm Nord TLMM, Shikra TLMM, SM6350 LPASS LPI, and IPQ9650 TLMM

   - Renesas RZ/G3L SoC

   - UltraRISC DP1000

  Improvements:

   - Handle pull up/pull down properly in the Renesas RZG2L driver

   - Fix up nVidia Tegra 234 DT bindings

   - Fix up pin definitions in the Qualcomm Eliza driver

   - Qualcomm PM8010 GPIO support in the PM8010

   - Qualcomm SM6115 EGPIO support in the SM6115

   - Switch Qualcomm LPASS LPI drivers to use runtime PM for power
     management

   - Clean up the Qualcomm Kconfig business a bit to include the
     necessary drivers for each subarch

   - Fix output glitch in the Amlogic (meson) A4 pin controller

   - Move the Airoha driver from the Mediatek directory to its own
     directory. It is too different from other Mediatek hardware

   - A slew of fixes to the Airoha AN7581 and AN7583 drivers"

* tag 'pinctrl-v7.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (151 commits)
  pinctrl: Export pinctrl_get_group_selector()
  pinctrl: Match DT helper types
  pinctrl: qcom: Register functions before enabling pinctrl
  pinctrl: meson: amlogic-a4: use nolock get range
  pinctrl: ultrarisc: Add UltraRISC DP1000 pinctrl driver
  dt-bindings: pinctrl: Add UltraRISC DP1000 pinctrl controller
  pinctrl: qcom: Remove unused macro definitions
  pinctrl: tegra: PINCTRL_TEGRA264 should depend on ARCH_TEGRA
  pinctrl: tegra: PINCTRL_TEGRA238 should depend on ARCH_TEGRA
  pinctrl: tegra238: add missing AON pin groups
  dt-bindings: pinctrl: tegra238: add missing AON pin groups
  pinctrl: airoha: an7583: remove undefined groups from pcm_spi pin function
  pinctrl: airoha: an7583: fix phy1_led1 pin function
  pinctrl: airoha: an7583: add missed gpio22 pin group
  pinctrl: airoha: an7583: fix gpio21 pin group
  pinctrl: airoha: fix pwm pin function for an7581 and an7583
  pinctrl: airoha: an7583: fix incorrect led mapping in phy4_led1 pin function
  pinctrl: airoha: an7581: fix incorrect led mapping in phy4_led1 pin function
  pinctrl: airoha: an7583: fix misprint in gpio19 pinconf
  pinctrl: airoha: an7581: fix misprint in gpio19 pinconf
  ...

Use pinctrl_find_gpio_range_from_pin_nolock() instead of
pinctrl_find_gpio_range_from_pin() when configuring a pin or
setting a GPIO value.

This avoids taking the lock and allows the code to be safely
called from interrupt context.

Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>

In Amlogic A9 SoC, subordinate bank reuse other master bank is
not from bit0, and subordinate bank reuse multi master banks.

This submission implements this situation.

Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>

When the system transitions from bootloader to kernel, the GPIO is
expected to keep driving high.

However, the Linux kernel first configures the pin direction and then
sets the output value. This may cause a brief low-level glitch on the
GPIO line, which can be problematic for regulator control.

By configuring the output value before switching the pin direction to
output, the glitch can be avoided.

This commit fixes the issue by swapping the configuration order.

Fixes: 6e9be3abb78c ("pinctrl: Add driver support for Amlogic SoCs")
Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Linus Walleij <linusw@kernel.org>

Accessing the pinconf-pins sysfs node may deadlock.

pinconf_pins_show() holds pctldev->mutex, and the platform driver
calls pinctrl_find_gpio_range_from_pin(), which tries to acquire
the same mutex again, leading to a deadlock.

Use pinctrl_find_gpio_range_from_pin_nolock() to fix this issue.

Fixes: 6e9be3abb78c ("pinctrl: Add driver support for Amlogic SoCs")
Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Linus Walleij <linusw@kernel.org>

Pull pin control updates from Linus Walleij:
 "Core changes:

   - Perform basic checks on pin config properties so as not to allow
     directly contradictory settings such as setting a pin to more than
     one bias or drive mode

   - Handle input-threshold-voltage-microvolt property

   - Introduce pinctrl_gpio_get_config() handling in the core for SCMI
     GPIO using pin control

  New drivers:

   - GPIO-by-pin control driver (also appearing in the GPIO pull
     request) fulfilling a promise on a comment from Grant Likely many
     years ago: "can't GPIO just be a front-end for pin control?" it
     turns out it can, if and only if you design something new from
     scratch, such as SCMI

   - Broadcom BCM7038 as a pinctrl-single delegate

   - Mobileye EyeQ6Lplus OLB pin controller

   - Qualcomm Eliza and Hawi families TLMM pin controllers

   - Qualcomm SDM670 and Milos family LPASS LPI pin controllers

   - Qualcomm IPQ5210 pin controller

   - Realtek RTD1625 pin controller support

   - Rockchip RV1103B pin controller support

   - Texas Instruments AM62L as a pinctrl-single delegate

  Improvements:

   - Set config implementation for the Spacemit K1 pin controller"

* tag 'pinctrl-v7.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (84 commits)
  pinctrl: qcom: Add Hawi pinctrl driver
  dt-bindings: pinctrl: qcom: Describe Hawi TLMM block
  dt-bindings: pinctrl: pinctrl-max77620: convert to DT schema
  pinctrl: single: Add bcm7038-padconf compatible matching
  dt-bindings: pinctrl: pinctrl-single: Add brcm,bcm7038-padconf
  dt-bindings: pinctrl: apple,pinctrl: Add t8122 compatible
  pinctrl: qcom: sdm670-lpass-lpi: label variables as static
  pinctrl: sophgo: pinctrl-sg2044: Fix wrong module description
  pinctrl: sophgo: pinctrl-sg2042: Fix wrong module description
  pinctrl: qcom: add sdm670 lpi tlmm
  dt-bindings: pinctrl: qcom: Add SDM670 LPASS LPI pinctrl
  dt-bindings: qcom: lpass-lpi-common: add reserved GPIOs property
  pinctrl: qcom: Introduce IPQ5210 TLMM driver
  dt-bindings: pinctrl: qcom: add IPQ5210 pinctrl
  pinctrl: qcom: Drop redundant intr_target_reg on modern SoCs
  pinctrl: qcom: eliza: Fix interrupt target bit
  pinctrl: core: Don't use "proxy" headers
  pinctrl: amd: Support new ACPI ID AMDI0033
  pinctrl: renesas: rzg2l: Drop superfluous blank line
  pinctrl: renesas: rzg2l: Fix save/restore of {IOLH,IEN,PUPD,SMT} registers
  ...

OF_GPIO is selected automatically on all OF systems. Any symbols it
controls also provide stubs so there's really no reason to select it
explicitly.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>

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 <ustc.gu@gmail.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>

Pull pin control updates from Linus Walleij:
 "Core changes:

   - Drop the unused devm_pinctrl_unregister() function

   - Move pretended generic pin control functionality out of the core
     and into the Amlogic AM4 driver. We have something better coming
     (hopefully)

  New hardware support:

   - Spacemit K3 (RISC-V) pin control support

   - Atmel AT91 PIO4 (ARM32) SAMA7D65 pin control support

   - Exynos9610 (ARM64) pin control support

   - Qualcomm Mahua TLMM (ARM64) pin control support

   - Microchip Polarfire MSSIO (RISC-V) pin control support

   - Ocelot LAN9645XF (multiplatform) pin control support

  Improvements:

   - Using a few more guards for locking

   - Various nonurgent fixes and tweaks"

* tag 'pinctrl-v7.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (73 commits)
  pinctrl: generic: move function to amlogic-am4 driver
  pinctrl: intel: Align Copyright note with corporate guidelines
  pinctrl: mediatek: remove unused drv_offset field
  pinctrl: canaan: k230: Fix NULL pointer dereference when parsing devicetree
  pinctrl: single: fix refcount leak in pcs_add_gpio_func()
  pinctrl: meson: amlogic-a4: Fix device node reference leak in bank helpers
  pinctrl: qcom: sm8250-lpass-lpi: Fix i2s2_data_groups definition
  pinctrl: core: Remove duplicate error messages
  pinctrl: core: Simplify devm_pinctrl_*()
  pinctrl: core: Remove unused devm_pinctrl_unregister()
  dt-bindings: pinctrl: spacemit: fix drive-strength check warning
  pinctrl: fix kismet issues with GENERIC_PINCTRL
  pinctrl: tangier: Join tng_pinctrl_probe() into its wrapper
  pinctrl: tangier: Remove duplicate error messages
  pinctrl: lynxpoint: Remove duplicate error messages
  pinctrl: cherryview: Remove duplicate error messages
  pinctrl: baytrail: Remove duplicate error messages
  pinctrl: intel: Remove duplicate error messages
  pinctrl: equilibrium: Fix device node reference leak in pinbank_init()
  dt-bindings: pinctrl: pinctrl-microchip-sgpio: add LAN969x
  ...

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 = <asjhdasjhlajskd>;
| 		config-item1;
| 	};
| };

| label: cfg {
| 	group1 {
| 		pinmux = <dsjhlfka>;
| 		config-item2;
| 	};
| 	group2 {
| 		pinmux = <lsdjhaf>;
| 		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 = <lskdf>;
| 		};
| 	};
| };

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 = <lskdf>;
| 	};
| };

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 <conor.dooley@microchip.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>