[PATCH v2] pinctrl: single: parse gpio-range as a raw array (O(N^2) -> O(N))

[Jordi T]

Hi Anshul,

Thanks for the review and for trying to reproduce it.

> I'm unable to reproduce the delays you have observed with the J722s EVM.
> Are you using a custom DT perhaps?

You're right that the default EVM build doesn't show a large delay, and it took
a board test on my side to understand why. No custom gpio-range property is
involved - it is the SoC's stock 7-entry main-domain gpio-range. What changes
is when pinctrl at f4000 (main_pmx0) is probed.

On the stock EVM defconfig it is first probed after relocation (caches on).
There, single_add_gpio_func() is only ~18 ms, and ~1 ms with this patch - easy
to miss in the overall boot unless you time the function directly. If you put a
get_timer() around single_add_gpio_func() on a stock EVM, you should see that
~18 ms -> ~1 ms.

The 723 ms in the commit came from a product configuration where the node is
probed before relocation (caches off). This happens during the pre-relocation
console bring-up: setting up the main UART applies its pin mux, which probes
main_pmx0 with caches off. That board also runs its LPDDR4 clocked down, as it
is an early sample and needed that for stability. The two factors decompose
cleanly from real measurements of the same unpatched function:

    caches off vs on, same board   : ~17x  (723 ms vs 41 ms post-reloc)
    reduced DDR vs EVM, caches on  : ~2x   (41 ms vs the EVM's 18 ms)

i.e. 723 ms = O(N^2) x caches-off x reduced-DDR. On the EVM's stock DDR, a
pre-relocation probe would land around ~300 ms. Either way, the patch removes a
genuinely quadratic full-FDT scan per entry and produces an identical
gpio-range list.

On the code points, all addressed in v2:

> Why rename 'ret' to 'ret_total' here?

Leftover, dropped. A single 'ret' is used only for the one phandle lookup.

> The size check is redundant

Agreed, dropped; v2 uses just if (!list).

> You could just do if (!phandle_i) ... is the validation required?

Correct, a valid gpio-range never has a null phandle. v2 reads the entries
directly; a zero phandle terminates the list, as in the original loop.

> I wonder if we can just allocate a pool of ranges[entries] ...

Done: v2 does a single devm_kcalloc(dev, entries, ...) and walks the array,
removing the per-entry allocation and its null check.

v2 follows shortly.

Thanks again.

Jordi