Re: [PATCH] mmc: pwrseq_simple: fix probe failure when CONFIG_RESET_GPIO is enabled

[Bartosz Golaszewski]

On Thu, Mar 5, 2026 at 11:46 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
>
> On 05/03/2026 11:04, Bartosz Golaszewski wrote:
> >
> >>> Philipp, Krzysztof: what do you think?
> >>
> >> I think this is a missing feature in reset-gpio.
> >> This driver could fall back to to devm_gpiod_get_array() also if
> >> devm_reset_control_get_optional_shared() returns -ENOENT instead of
> >> erroring out (maybe -ENOTSUPP would be a better return code for [1]?).
> >>
> >
> > I did not write the initial version but Krzysztof: is there any reason we only
> > support a single, two-cell GPIO? Would it be problematic to support any kind of
> > reset GPIO setup?
>
> It was only due to limitation of my initial solution - see even a TODO
> note in reset/core.c. I think the problem I had is that GPIO specifier
> without flags (so cells=1) would mess with GPIO_LOOKUP(). And if we have
> cells=3, where do the flags are? If you assume flags are last argument,
> that's an implied ABI encoded in the reset core.
>
> Well, heh, implied ABI that 2nd argument are flags is already there, so
> the code is partially hacky, I agree.
>
> So honestly I believe that GPIO core should handle all this mapping of
> original reset-gpios property into platform data to reset-gpio driver.
> That's the answer for your question "would it be problematic".
>
>
> For reference, original patch:
> https://lore.kernel.org/all/20240129115216.96479-5-krzysztof.kozlowski@xxxxxxxxxx/

Philipp just picked up the reset core rework, once it's in linux-next,
I'll try to extend the support to accept multiple entries in
reset-gpios.

Bart