The logic was updated without modifying the comment above it

Fixes: 72b8c6d1ebf ("pinctrl: don't fall back to pinctrl_select_state_simple()")

Signed-off-by: Philip Molloy <philip.molloy@analog.com>

As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

Prepare v2024.07-rc3

When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

Linux kernel Documentation/devicetree/bindings/gpio/gpio.txt define the
format of the gpio-ranges prop as:

  The format is: <[pin controller phandle], [GPIO controller offset],
                  [pin controller offset], [number of pins]>;

  Example:

      gpio-ranges = <&foo 0 20 10>, <&bar 10 50 20>;

  This means:
  - pins 20..29 on pin controller "foo" is mapped to GPIO line 0..9 and
  - pins 50..69 on pin controller "bar" is mapped to GPIO line 10..29

For this example, a call to pinctrl_gpio_get_pinctrl_and_offset() using
offset 10 incorrectly return pin controller "foo" instead of "bar".

Fix this by using an exclusive range check.

Fixes: d0bb00adccb8 ("pinctrl: fix pinctrl_gpio_get_pinctrl_and_offset for gpio-ranges array")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Quanyang Wang <quanyang.wang@windriver.com>

Remove <common.h> from this driver directory and when needed
add missing include files directly.

Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>

Pinconfig nodes normally bind recursively with PINCTRL_FULL and
PINCONF_RECURSIVE enabled. However, during U-Boot proper pre-relocation
any node marked with e.g. bootph-all will not bind unless its parent is
also marked for pre-reloc.

  group1 {
      pinconf1 {
          bootph-all;
      };
  };

This cause the following warning message to be shown during U-Boot
proper pre-reloc stage on Rockchip devices, e.g on RK3568:

  ns16550_serial serial@fe660000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19

and on RK3328:

  ns16550_serial serial@ff130000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19

Check pinconfig nodes pre-reloc status recursively to fix this and to
make pinconfig_post_bind work same at both U-Boot proper pre-reloc and
at TPL/SPL stage.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>

Sometimes a multi-element array is used for "gpio-ranges" property in
dts file:

    qe_pio_e: gpio-controller@1460 {
        ......
        gpio-ranges = <&pinctrl1 0 20 10>, <&pinctrl2 10 50 20>;
        ......
    };

But the function pinctrl_gpio_get_pinctrl_and_offset can't handle this
case because the "index" argument passed to dev_read_phandle_with_args
is fixed to be "0". Use a loop to traverse the array to fix it.

Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com>

Fix the copy and paste error.

Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Simon Glass <sjg@chromium.org>

Don't define an empty version for pinconfig_post_bind(). Just guard the
call and let the linker garbage collection do the rest. This way, we
also don't have to do any guesswork.

Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Marek Vasut <marex@denx.de>